The present invention relates generally to smart cards. In particular, the present invention relates to a system and method for standardized, integrated and automated production of smart cards by using a script language.
The present invention is applicable to smart cards. Also termed chip cards, integrated circuit cards, memory cards or processor cards, a smart card is typically a credit card-sized plastic card that includes one or more semiconductor integrated circuits. A smart card can interface with a point-of-sale terminal, an ATM, or with a card reader integrated with a computer, telephone, vending machine, or a variety of other devices. The smart card may be programmed with various types of functionality such as a stored-value application, a credit or debit application, a loyalty application, cardholder information, etc. Although a plastic card is currently the medium of choice for smart cards, it is contemplated that a smart card may also be implemented in a smaller form factor, for example, it may attach to a key chain or be as small as a chip module. A smart card may also be implemented as part of a personal digital assistant, telephone, or take a different form. The below description provides an example of the possible elements of a smart card, although the present invention is applicable to a wide range of types of smart cards.
A smart card may include a microprocessor, random access memory (RAM), read-only memory (ROM), non-volatile memory, an encryption module (or arithmetic unit), and a card reader (or terminal) interface. Other features may be present such as optical storage, flash EEPROM, FRAM, a clock, a random number generator, interrupt control, control logic, a charge pump, power connections, and interface contacts that allow the card to communicate with the outside world. Of course, a smart card may be implemented in many ways, and need not necessarily include a microprocessor or other features.
The microprocessor is any suitable central processing unit for executing commands and controlling the device. RAM serves as temporary storage for calculated results and as stack memory. ROM stores the operating system, fixed data, standard routines, look up tables and other permanent information. Non-volatile memory (such as EPROM or EEPROM) serves to store information that must not be lost when the card is disconnected from a power source, but that must also be alterable to accommodate data specific to individual cards or changes possible over the card lifetime. This information includes a card identification number, a personal identification number, authorization levels, cash balances, credit limits, and other information that may need to change over time. An encryption module is an optional hardware module used for performing a variety of encryption algorithms. Of course, encryption may also be performed in software. Applied Cryptography, Bruce Schneier, John Wiley and Sons, Inc., 1996 discusses suitable encryption algorithms and is hereby incorporated by reference.
The card reader interface includes the software and hardware necessary for communication with the outside world. A wide variety of interfaces are possible. By way of example, the interface may provide a contact interface, a close-coupled interface, a remote-coupled interface, or a variety of other interfaces. With a contact interface, signals from the integrated circuit are routed to a number of metal contacts on the outside of the card which come in physical contact with similar contacts of a card reader device. A smart card may include a traditional magnetic stripe to provide compatibility with traditional card reader devices and applications, and may also provide a copy of the magnetic stripe information within the integrated circuit itself for compatibility.
Various mechanical and electrical characteristics of a smart card and aspects of its interaction with a card reader device are described in Smart Card Handbook, W. Rankl and W. Effing, John Wiley and Sons, Ltd., 1997, and are defined by the following specifications, all of which are incorporated herein by reference: Visa Integrated Circuit Card Specification, Visa International Service Association, 1996; EMV Integrated Circuit Card Specification for Payment Systems, EMV Integrated Circuit Card Terminal Specification for Payment Systems, EMV Integrated Circuit Card Application Specification for Payment Systems, Visa International, Mastercard, Europay, 1996; and International Standard; Identification Cardsxe2x80x94Integrated Circuit(s) Cards with Contacts, Parts 1-6, International Organization for Standardization, 1987-1995.
In creating such a smart card, multiple steps are typically performed at different physical locations. One of these steps is the installation of application software. Applications intended for a smart card are typically developed by a smart card manufacturer or third party at the direction of a card issuer. The card issuer is often a bank or other financial institution, but may also be a telecommunication network operator, a merchant operating a fidelity or loyalty program, or even an agent acting for an issuer. The applications, typically written in assembly code for a specific chip, are given to the chip manufacturer that produces such chips. The chip manufacturer then burns the application software into chips on a silicon wafer. The wafer is then cut up and the chips are then sent back to the smart card manufacturer. The smart card manufacturer then embeds the chips into plastic cards.
Once the chips are embedded into plastic cards, the card manufacturer performs an initialization process. During initialization, data and data structures that are common to an entire batch of cards are installed on the cards. For example, data common to an entire batch of cards may include printing of graphics for bank or network logos, information such as a bank identification number (BIN), or the currency used by the application, such as U.S. dollars or German marks.
After initialization, a personalization process typically occurs. The personalization process may be performed by the card manufacturer, but is often performed at a specialized personalization bureau. During personalization, the smart card is loaded with data which uniquely identifies the card. For example, the personalization data can include a maximum value of a stored value card, a personal identification number (PIN), a cardholder account number, the expiration date of the card, or cryptographic keys.
The personalization bureau is typically a third party contracted by the smart card issuer to personalize their smart cards. The personalization bureau is often in a location different from the location of the smart card issuer or that of the card manufacturer. For each batch of cards, the cardholder information data must typically be pre-processed by the issuer (sorted, formatted and placed in a personalization file). Typically, each personalization bureau requires a specific file format. The issuer must modify its cardholder information data for each personalization bureau that the issuer deals with. Otherwise, the personalization bureau must modify its file formats for the different issuers with which it operates. Either way, the personalization data file must typically be redesigned for almost every change made to the specifications for a batch of cards. During personalization, personalization equipment coupled to a security device is typically used. The personalization equipment contains software which interacts with the smart card software to load personalization data. The security device is used to store cryptographic keys or other sensitive information which may be needed in the personalization process. After personalization, the cards are distributed to cardholders.
One technique for smart card personalization is described in U.S. patent application Ser. No. 08/755,459 (U.S. Pat. No. 5,889,941), entitled xe2x80x9cSystem and Apparatus for Smart Card Personalization,xe2x80x9d assigned to UbiQ Incorporated. This application teaches a smart card personalization system that maintains a database containing card application data, card operating systems data, issuer templates of input cardholder data, and personalization equipment data, to dynamically build configurations to produce issued (personalized) smart cards.
Conventionally, equipment associated with smart card production is pre-programmed. Every piece of software is individually customized for a particular set of specifications for a batch of cards, such as for the combination of the smart card application and the chip itself. Accordingly, for virtually every change made to the specifications for a batch of smart cards software must be rewritten for each piece of equipment used in the smart card manufacturing process. This individual rewriting of software for virtually every piece of equipment used in smart card manufacturing can be very time consuming, labor intensive, and expensive.
Additionally, the conventional methods of preparing smart cards are not practical for preparing multi-application smart cards. A multi-application smart card may come in many forms and from a variety of manufacturers. In one example, the smart card may use the Multi-application Operating System (MULTOS) managed by Maosco Ltd. In another example, the multi-application smart card may use the xe2x80x9cOpen Platformxe2x80x9d architecture which is described in further detail in U.S. patent application Ser. Nos. 09/046,993 and 09/046,994, both of which are assigned to Visa International Service Association and both incorporated herein by reference for all purposes. In general, these above types of smart cards are referred to herein as multi-application smart cards.
A single-application (or traditional) smart card typically comes with its software application already permanently burned into the chip on the card. It is generally not feasible to add more applications to the card. Also, applications written for a card manufactured by a first manufacturer (for example, Gemplus), would not necessarily run on a card manufactured by a second manufacturer (for example, Schlumberger). With an Open Platform smart card, applications are designed to be capable of being added to a card post-issuance, and applications should be designed to be capable of being run on any Open Platform card, regardless of the card manufacturer. These Open Platform smart cards may allow the loading of an application and/or objects from an application server onto a card via a card acceptance device. This loading can occur either before or after card issuance in a secure and confidential manner. Additionally, the Open Platform smart card facilitates multiple ownership and control of various applications of the smart card.
In one embodiment of the Open Platform card, the card when produced contains the software infrastructure needed to support the loading, initialization, personalization and the running of applications. This infrastructure may include the card""s operating system, a card executive (the main control program for the chip), a card domain (the software application representing the issuer), and any number of security domains (each representing an application provider). In one particular embodiment suitable for use with applications written in the JAVA programming language, the infrastructure includes a JAVA interpreter (the JAVA xe2x80x9cvirtual machinexe2x80x9d. The JavaCard(trademark) virtual machine (JCVM) works well in this embodiment.
An Open Platform smart card may also provide confidential information to an application in a smart card. In a multi-application smart card, a privileged application referred to as a security domain is used as a confidential representative of an application provider. The security domain contains cryptographic keys which are kept confidential from the smart card issuer, thus allowing separation of cryptographic security between the issuer and the application provider. When a new application is loaded onto a smart card, the newly loaded application utilizes its associated security domain""s cryptographic service. A privileged application representing the issuer, referred to as a card domain, approves of commands (such as commands for initialization and personalization) by invoking the security domain""s cryptographic service. In this manner, a post-issuance download of an application onto an issued Open Platform smart card can be accomplished.
As mentioned above, the conventional methods of preparing smart cards are not practical for preparing multi-application smart cards. Few actors are involved in single-application smart card production: one issuer; one or two card manufacturers; and one or two personalization bureaus. True multi-application smart cards will involve new and more actors, including one or more application providers who develop/operate applications and contract with the primary issuer to load their applications onto the issuer""s cards. Each of these application providers may themselves contract with their own (and different) personalization bureaus. Such multi-application smart cards might then encounter a multi-step load and personalization process, at multiple locations (one for each of the different applications), before they could be actually issued. Or, such multi-application smart cards might be issued with only a partial set of loaded and personalized applications, and might require further personalization.
Conventional methods for issuing and distributing cards require that hardware used to initialize and personalize smart cards be reprogrammed for each new combination of a chip and a particular set of applications. Additionally, there are typically no provisions for loading application code onto the card, other than the code burned into card silicon at manufacture.
The production of cards with multiple applications can be extremely complex and is not often attempted. For every different combination of multiple applications to be loaded onto the smart card and personalized, the equipment used during the smart card manufacturing process would need to be reprogrammed for each different combination of applications. Similarly, for every different combination of multiple applications, the personalization data file would need to be redesigned for each combination. For every different relationship between the issuer and the multiple application providers, the personalization data would need to be redesigned and split into different files for each different relationship. Accordingly, even if it were practical to produce multi-application cards via the conventional card manufacturing process, only a predetermined set of chips and applications could be produced without incurring a substantial cost per card.
It would be desirable to automate the process of manufacturing smart cards such that large batches of smart cards could be manufactured, while allowing each card to be customized for each issuer, application provider, and cardholder. It would also be desirable to mass produce multi-application smart cards at a reasonable cost. It would be further desirable to allow unique variations in the combination of applications loaded onto an individual card, and further, to allow unique variations to be loaded onto individual cards post-issuance. Further, it would also be desirable to be able to reproduce a lost or stolen card at locations other than at the card issuer or personalization agent, such as in a bank branch, without a substantial loss of time.
It can also be difficult to load applications onto a card post-issuance when other applications have already been loaded. If there is not enough memory for a new application, if a new application would conflict with an existing application, or if the operating system version required by the application is different from that currently on the card, it might be inadvisable to load a new application. At the very least, a new application might not function even if a post-issuance load were successful. Therefore, it would further be desirable to be able to successfully load applications onto issued smart cards with assurances that the load will be successful and the application will function as desired.
To achieve the foregoing, and in accordance with the purpose of the present invention, a system and method are disclosed that allow automated mass preparation of smart card data and mass production of smart cards. These smart cards can be traditional single application smart cards or multi-application smart cards which include more than one application or have the ability to load more than one application. Additionally, an embodiment of the present invention allows mass production of smart cards which may be customized for each individual card issuer, application provider, and cardholder.
The automated process according to an embodiment of the present invention uses a scripting language which allows the combination of all production aspects of a card in a unified script. This script is automatically produced using the scripting language and its particular syntax rules and can be easily altered and customized. The script is used in a card production system which can automatically produce a custom smart card. In one embodiment of the present invention, a customer may go to a single location (such as a bank branch), and obtain a custom smart card produced for him during a single visit to the bank. Other embodiments of the present invention also allow a card to be updated with new or revised applications post-issuance.
According to one embodiment of the present invention, a script is produced for use with card manufacturing equipment such that the card manufacturing equipment need not be reprogrammed for every change in specific card requirements. The card manufacturing equipment follows the directions of the script to create a smart card complying with the specific card requirements. The script itself may easily be altered to allow customization of a smart card.
To automate the complex process of creating smart cards, smart cards are described using different profiles, for example, a card profile, application profiles, and an issuer profile. The card profile, for example, describes the resources available on the card and documents the card""s software infrastructure, the available resources (including all types of memory), any applications already on place on the card, the life cycle status of those applications, and physical attributes of the card. To help determine which applications may coexist on the card, application requirements are documented in an application profile. An application profile identifies the application source code and includes the resource requirements of an application such as memory, operating system version, security, and card physical requirements.
For a given smart card to be produced, the selected application profiles of applications to be installed on the card are compared to ensure their compatibility. These profiles are also checked for compatibility with any number of card profiles to find a suitable card profile. A card creation script may then be built based upon the selected application profiles and card profile. In one embodiment, the card creation script is a natural language description of the functions and data required to create a multi-application or a traditional (single application) smart card. This card creation script may encompass the initialization and personalization for both types of cards, and may further include the loading of application code for multi-application cards.
In one embodiment the script is vendor-independent and is a standardized method for describing the creation of virtually any smart card. A script is machine readable, thus allowing vendors who write their own parsers to use the script to drive the controllers of their own personalization equipment. The initialization portion of the script may be used to drive the equipment performing initialization. Alternatively, the entire script may be used to drive a desktop unit that produces one-off cards in a bank branch. Scripts for suites of applications may be created and archived allowing for creation of a single custom card or for the creation of millions of cards. In another embodiment, the script drives a remote server that communicates with a local card reader interface into which the smart card is physically inserted, thus allowing remote on-line personalization and/or initialization, such as in a post-issuance process where the card is in the hands of the cardholder.
Thus, embodiments of the present invention allow automation of what is now a complex manual process. The loading of applications onto cards is automatic using techniques of the present invention; the previously manual process of programming the initialization and personalization hardware for each combination of card and applications may also be automated according to embodiments of the invention. In this manner, embodiments of the invention permit rapid development and deployment of smart cards.
In a further embodiment of the invention, an updated card profile is also produced by the script builder. The updated card profile describes the resources of the card once one or more applications have been loaded and the card issued. Thus, the original card profile (describing a blank card) is updated to describe a particular card product. The updated card profile may be used when it is desired to load applications onto a card post-issuance. By comparing the updated card profile to the desired application profiles to be loaded post-issuance, a new card script may be created that will succeed in loading the applications and provide assurances that the new applications will function as desired.